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On the cover sheet of the patent, the following non-patent literature prior art reference, cited 

by Patentees, was not identified: 

"Miller et al. ? "BLUETOOTH REVEALED" 2001 Prentice Hall PTR; pp. 
164-176 and 217-222". 

DISCUSSION 

On June 27, 2001, Patentees filed US application Serial No. 09/891,382, which ultimately 
matured into the '460 patent on the Issue Date of January 11, 2005. Accompanying the original 
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first Form PTO-1449 Information Disclosure Citation ("the first PTO-1449") citing five separate 
pieces of prior art, i.e., three US patents (5,822,309; 6,134,587; and 6,104,712), one international 
publication (WO 01/37497), and the non-patent literature publication identified in the previous 
section. A second Information Disclosure Statement ("the second IDS"), which included a second 
Form PTO-1449 Information Disclosure Citation ("the second PTO-1449") and cited three 
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Examiner. The copy of the first PTO-1449 for reference citation "AR" (the above publication to 
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Miller et al.) under the "OTHER DOCUMENTS" section, however, was neither initialed or crossed 
out by the Examiner. A copy of the first PTO-1449 that accompanied the non-final Office Action is 
attached hereto. Also attached, for the convenience of the USPTO, is an additional copy of the 
subject Miller et al. publication for which Patentees are again seeking citition via a Certificate of 
Correction 
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10, a request that the Examiner "consider Reference AR listed on the Form PTO-1449 filed on June 
27, 2001", i.e., the first PTO-1449. A second request for consideration of the "AR" reference 
citation on the first PTO-1449 was also included in Patentees Amendment and Request for 
Reconsideration filed June 22, 2004 in response to the final Office Action of April 7, 2004. 

Notwithstanding Patentees' two separate requests for consideration of reference "AR" cited 
on the first PTO-1449, the '460 patent issued without the identification of the Miller et al. 
publication (Reference "AR") under IMD Code (56), in a subsection titled "OTHER 
PUBLICATIONS", on the cover page of the '460 patent. As such, it would appear that the 
Examiner erred by (1) sending out an incomplete copy of the Examiner initialed, dated, and signed 
first Form PTO-1449 with the non-final Office Action, and (2) not subsequently correcting such 
error in response to Patentees' repeated requests for correction thereof 
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In fact the programming model suggested in RFCOMM is a spe- 
cific instance of the generalized model suggested in the section entided 
"The Application Group" in Chapter 5 (refer back to Figure 5.4). In this 
case we suggest a thin layer of Bluetooth adaptation software for legacy 
applications that maps platform APIs to specific functions of the Blue- 
tooth protocol stack. In the case of RFCOMM, which provides an emu- 
lated serial port, this adaptation software (which the specification calls a 
port emulation entity) needs to map the application's interactions with a 
"real" RS-232 serial port to the equivalent operations for the 
RFCOMM emulated serial port For the most part these are expected 
to be initialization operations such as activating and configuring the 
serial port and establishing a serial connection; and finalization opera- 
tions such as terminating the serial connection. Once a general serial 
port adaptation layer is in place in a system, all those legacy applica- 
tions that use serial communication ought to be enabled to use Blue- 
tooth transports via the.RFCOMM emulated serial port 

As pointed out earlier, the use of serial ports is prevalent in devices 
and environments where Bluetooth wireless communication is likely to 
be used, and the majority of the version 1:0 profiles depend upon serial 
port communications. In the absence of a version 1.0 specification for 
general networking, the RFCOMM protocol provides an important 
utility for legacy applications. The implementation of this protocol, 
along with adaptation software for legacy applications that use serial 
communications, permits many simple cable replacement applications 
of Bluetooth wireless communication. 



The Service Discovery Protocol (SDP) 



Service discovery is a process by which devices and services in net- 
works can locate, gather information about and ultimately make use of 
other services in the network. In traditional networks such as LANs, 
these services might be statically configured and managed by a network 
administrator. In these environments, the administrator or end user per- 
forms the configuration that is necessary for one participant in the net- 
work to use the services of some other network member. For example, a 
PC user might specify all of the information associated with a network 
e-mail service (including the mail server name, user and account names, 
e-mail type, capabilities and options, and so on) to the PC's operating 
system and applications; once all this information is entered into the PC 
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and associated with that e-mail service, then the e-mail service becomes 
available to the PC user. 

Administered network services of this sort may be fine for many 
fixed networks but are really not suitable for temporary mobile net- 
works (ad hoc networks) such as those that might be formed using Blue- 
tooth wireless communication. In these environments a more dynamic, 
flexible and adaptive solution is needed. Graham, Miller and Rusnak 
[Graham99] observe the growing incidence of these ad hoc networks 
and the resulting demand for self-configuring systems: 

The emergence of information appliances and new types of 
connectivity is spurring a new form of networking: unmanaged, 
dynamic networks of consumer devices that spontaneously and 
unpredictably join and leave the network. Consumers will expect 
these ad hoc, peer-to-peer networks to automatically form within 
the home, in very small businesses and in networked vehicles. ... 

To achieve the goals of simplicity, versatility and pleasurabil- 
ity, the appliances and the network(s) they join must just work right 
out of the box. By just work we mean that the participants on the net- 
work must simply self configure. By self configure we mean that these 
network devices and services simply discover each other, negotiate 
what they need to do and which devices need to collaborate with- 
out any manual intervention. 5 

Protocols for service discovery can help to enable this self-configu- 
ration. Since much of the interdevice communication in Bluetooth 
usage scenarios is of a peer-to-peer, ad hoc nature, the SIG determined 
that a service discovery protocol in the stack could provide significant 
value. The resulting protocol, known as SDP, is a central component of 
nearly all of the profiles and usage cases, both existing and foreseen. 

The service discovery concept is not new or unique to Bluetooth 
wireless technology. Numerous service discovery technologies are avail- 
able in the industry, some of them well known. As is evident in other 
layers of the protocol stack, the SIG is content to adopt existing proto- 
cols where it makes sense to do so. In the case of service discovery, 
though, the SIG developed its own protocol unique to and optimized 
for Bluetooth wireless communication rather than adopting some other 
service discovery protocol in the industry. The reasons should become 
evident as we review SDP's development in the next section. 



5. Reprinted by permission from Discovering Devices and Services in Home Networking, copyright 
(1999) by International Business Machines Corporation. 
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SDP Development 

The need for a service discovery component in the protocol stack was 
recognized early in the process of developing the specification, 
although direct work on SDP did not commence until later. In early 
and mid 1998, many of the initial participants in the SIG were focusing 
on the transport protocols and key middleware protocols like 
RFCOMM. While the need for other protocols had been identified, 
task forces of experts to develop these protocols had not been assem- 
bled in all cases. In the case of SDP, some preliminary work had been 
started at Intel and Ericsson in the summer of 1998. 

In early internal versions of the specification, service discovery, 
was a section within the L2CAP part of the specification. Initially, 
L2CAP channels were modeled after a computer bus, and service, dis- 
covery was concerned exclusively with the transport of Plug and Play 
parameters over this virtual bus. In September 1998, at a SIG meeting 
in London, 6 author Bisdikian suggested that the addition of a transport 
protocol for Plug and Play parameters unnecessarily complicated the 
L2CAP specification, and that such a protocol merited its own service 
discovery portion of the. Bluetooth specification. 

In October 1998 the SIG held a developers conference in Atlanta 
which author Miller attended. Based upon conversations during that 
conference, Miller was asked to chair the service discovery task force of 
the SIG's software working group shortly thereafter. The following 
month the newly constituted group met for the first time as a formal 
SDP task force. 

While at this time (late 1998) many of the protocol layers had been 
under development for several months, with some of them approaching 
levels of stability that would soon near final stages, SDP was still really 
in. a nascent state of forming the requirements and the beginning of a 
proposal to address those requirements. . 

Among the identified objectives for Bluetooth SDP were: 

Simplicity: Because service discovery is a part of nearly every 
Bluetooth usage case, it is desirable that the service discovery process 
be as simple as possible to execute. For the SDP task force this also 
implied the reuse of other Bluetooth protocols to the extent possible. 
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6. To advance the development of the specification, face-to-face meetings among SIG members 
have taken place in many different countries reflective of the multinational constituency of the 
SIG membership. 
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Compactness: As described in previous chapters, the formation of 
Bluetooth communication links between two devices can in some 
cases be time consuming. Since service discovery is a typical opera- 
tion to perform spon after links are established, the SDP air-interface 
traffic should be as minimal as feasible so that service discovery does 
not unnecessarily prolong the communication initialization process. 
Versatility: The version 1.0 specification includes a number of pro- 
files, and future revisions will undoubtedly add to the list, which is 
expected to continue to grow. Since an exhaustive set of profiles, 
usage cases and associated services cannot be foreseen or accurately 
predicted, it is important for SDP to be easily extensible and versatile 
enough to accommodate the many* new services that will be 
deployed in Bluetooth environments over time. To support this 
objective the SDP task force chose a very broad definition of "ser- 
vice," so that the widest possible spectrum of features (services) could 
be supported in the future. 

Service location by class and by attribute: In the dynamic ad 
hoc networking environment it is important to enable client devices 
and users to quickly locate a specific service when they already know 
exactly (or at least largely) what they are looking for. It should be 
straightforward to search for a general class of service (say, "printer"), 
for specific attributes associated with that service (for example, "color 
duplex IBM printer") and even for a specific instance of a service 
(such as a specific physical printer), 

Service browsing: In addition to searching for services by class or 
attribute, it is often useful simply to browse the available services to 
determine if there are any of interest This is a different usage scenario 
than is searching for specific services, and in some respects it is almost 
a contrary objective, but the SIG agreed that both usage models have 
merit, and they developed a solution that uses a consistent method to 
support both specific service searching and general service browsing. 

These objectives led to the development of requirements for a sim- 
ple, flexible protocol and data representation for service discovery in 
the protocol stack. Popular industry discovery protocols were reviewed, 
but none seemed to provide a good match for the SDP objectives- 
many of these technologies provide robust and comprehensive service 
discovery and access methodologies, but the SIG was really looking for 
a fairly low-level, simple, narrow-in-scope solution that met the rather 
modest objectives noted above in a straightforward manner. At this 
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point Motorola® approached the SIG with a proposal to contribute 
some technology, suitable for use in Bluetooth service discovery, that 
Motorola had had under development for several years. Through a con- 
tributing adopter agreement Motorola was then able to participate in 
the SDP task force of the SIG (and in fact the Motorola representative 
served as editor of the SDP specification), with their contributed tech- 
nology forming the basis for SDP. 

So with the SDP effort underway in November 1998, the SDP 
requirements and scope were agreed upon and the specification devel- 
opment ensued, incorporating the ideas contributed by Motorola along 
with the many contributions by the other SIG member companies. 
Even though the real SDP work started later than for many other proto- 
cols, through hard work the SDP specification was completed, ratified 
and published along with the bulk of the other protocols in the stack in 
July 1999 in the version 1.0 specification. 

The following sections describe some of the k6y facets of the SDP 
specification, including why these elements are significant and the ratio- 
nale for including them in the specification. 



SDP Examined 

Key to understanding the development of SDP is to understand its 
motivation and requirements. In fact, this information is included at the 
beginning of the SDP portion of the specification. As noted above, SDP 
is intended to allow devices in Bluetooth environments to locate avail- 
able services; As the specification states, these environments are qualita- 
tively different from traditional networks such as LANs or WANs. 
Devices and services are likely to come and go frequendy in Bluetooth 
piconets. Thus SDP was developed to satisfy the requirements of such 
environments. 

Some of the notable requirements for SDP are listed in the preced- 
ing section. These are also mentioned and expanded upon in the speci- 
fication. Also of interest are those items that SDP does not attempt, to 
address, at least in version 1.0 of the specification. 8 The "Non-Require- 
ments and Deferred Requirements" portion of the SDP specification 



Subsequent to publication of the version 1.0 specification, efforts were begun to map some of 
the leading industry service discovery technologies to the Bluetooth stack. Chapter 16 gives 
details of this work. 

Of these, the Bluetooth SIG might choose to enhance SDP in the future to address some of the 
issues. Many, however, are likely to remain outside the scope of Bluetooth SDP, since some of 
the issues can be and are addressed by industry discovery protocols, which Bluetooth SDP can 
accommodate, as explained in the main body text 
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can be summarized largely with the statement that SDP is narrow in 
scope, focusing primarily on discovery in Bluetooth environments and 
leaving more sophisticated service functions and operations to other 
protocols which might be used in conjunction with SDP. 

SDP includes the notion of a client (the entity looking for services) 
and a server (the entity providing services). Any device might assume 
either role at a given time, acting sometimes as a service client and 
sometimes as a service provider (server). 

The service provider needs to maintain a list of service records that 
describe the service(s) it provides; this list is called the service registry. A 
service record is simply a description of a given service in a standard 
fashion as prescribed by the specification. A service record consists of a 
collection of service attributes containing information about the class of 
the service (which might be printing, faxing, audio services, information 
services, and so on), information about the protocol stack layers that are 
needed to interact with the service, and other associated information 
such as human-readable descriptive information about the service. Fig- 
ure 8.3 illustrates the general structure of a service registry with its con- 
stituent service records. Shown is a set of services, each with a service 
record handle (depicted by srvRecHnd[0] through srvRecHnd(j]) and a 
set of attributes per service (shown as srvAttribute[0:a] through srvAt- 
tribute(j:c]). Further explanation of the content of these service records 
follows. 
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Figure 8.3 

General SDP service registry structure. 
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Service records consist of both universal service attributes and service- 
specific attributes. The universal service attributes are simply those parts 
of the service record that apply to all types of services, such as the ser- 
vice class and protocol stack information noted above. Service-specific 
attributes are those parts of the service record that are relevant only for 
a specific class or instance of a service. Examples of service-specific 
attributes could include attributes specific to a printing service (such as 
color, duplex and finishing capabilities), attributes specific to an audio 
service (such as data rate or encoding scheme) or attributes specific to a 
dial-up. networking service (such as serial port configuration or modem 
setup information). Volume 1 of the specification includes definitions 
for a set of universal service attributes (those which could apply to all 
types of services), but it does not include service-specific attributes, 
since it would be impossible to specify and predict all of the attributes 
for every imaginable type of service. Service-specific attributes are 
defined in profiles (volume 2 of the specification). Since profiles 
describe a usage scenario and how the protocol stack is used, they effec- 
tively define a service. So, for example, the headset profile defines the 
service specific attribute "remote audio volume control" that applies to 
the headset service. While the universal service attributes can apply to 
all types of services, this does not mean that they are mandatory-it is 
not required that every service include every universal service attribute 
in its service record. In fact, only two of the universal service attributes 
are mandatory: the service class attribute, which defines the class, or 
type of the service, and the service record handle, which serves as a 
pointer, or reference to the service record and is used by the client to 
access the server's service record. 

Each service attribute in a service record consists of an attribute 
identifier (attribute ID, a 16-bit unsigned integer) and an attribute value 
associated with that attribute ID. Each entry of the service record is one 
of these (attribute, value) pairs. Because these attributes describe all sorts 
of information, SDP uses the concept of a data element for the attribute 
value. A data element is simply a self-describing piece of data. The first 
part of a data element consists of a one-byte header that tells the actual 
type and size of the data. The remainder of the data element consists of 
the data values for the attribute, of the format and size specified by the 
data element header. Through the use of data elements, SDP allows 
attribute values to be of several types, including strings, Booleans, 
signed and unsigned integers of various sizes, and universally unique 
identifiers (UUIDs, discussed further below). Moreover, these data 
types can be lists of the scalar elements noted above, thus providing a 
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flexible representation for the many data types of which attribute values 
might be composed. 

Discovering a service in Bluetooth wireless communication 
reduces to a simple operation: the client specifies the service(s) of inter- 
est and the server responds, indicating any available services that match 
what the client specified. In practice for SDP this consists of the client's 
sending a request in the form of an SDP protocol data unit (SDP_PDU) 
that indicates what service(s) it is searching for and the server's sending 
back a response, also in the form of an SDP.PDU, that indicates what 
services match the request that the client has made. To accomplish this, 
the client needs a standard way to represent the service(s) of interest 
and the server needs a standard method to match its available services 
against the client's specification. For this purpose SDP introduces uni- 
versally unique identifiers (UUIDs). 

A UUID is a concept adopted from the International Organiza- 
tion for Standardization (ISO). UUIDs are 128-bit values that can be 
created algorithmically and, generally speaking, can be virtually guar- 
anteed to be entirely unique-no other UUID ever created anywhere 
will have the "same value. One advantage of using UUIDs is that new 
identifiers can be created for new services without requiring a central 
registry of identifiers maintained by the SIG, although the SIG does 
include a list of "well-known" UUIDs in the specification for those ser- 
vices related to the published profiles. So a client looking for a service 
just specifies the UUID associated with that class of service (or with the 
specific service) in its service search request, and the service provider 
matches that UUID against those of the services it has available to gen- 
erate its response. 

The SDP_PDUs exchanged between the client and server are sim- 
ple transactions. The general SDP protocol flow requires only two 
transactions; the specification defines three different SDP transactions, 
but the third is. really just a composite of the first two. A typical SDP 
transaction consists of: 

1. Client sends a request to search for service(s) of interest; server 
responds with handles to services that match the request 

2. Client uses the handle(s) obtained in step 1 to form a request to 
retrieve additional service attributes for the service(s) of interest 



9. This concept is sometimes hard to grasp* but universally unique identifiers can in fact be cre- 
ated. While there is an extremely small chance of duplication, UUIDs as defined by ISO (see 
[IS096]) are quite sufficient for the purposes of Bluetooth SDP and turn out to be quite valu- 
able in this context 
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Following the above transaction, the client will presumably use the 
information obtained in step 2 to open a connection to the service using 
some protocol other than SDP to access and utilize the service. Step 1 is 
called the ServiceSearch transaction and consists of the ServiceSearchRe- 
quest SDP_PDU from the client to the server and the ServiceSearch- 
Response SDP_PDU in return (from server to client). As noted above, 
the ServiceSearchResponse SDP_PDU contains handles to one or more 
services that match the request In step 2, the client presents one or 
more of those handles in a ServiceAttributeRequest SDPJPDU which 
causes the server to generate a ServiceAttributeResponse SDPJPDU; this 
exchange is the ServiceAttribute transaction. In the ServiceAttributeRe- 
sponse SDP_PDU will be the attribute values associated with the ser- 
vice that correspond to the attribute IDs that the client specified in the 
ServiceAttributeRequest SDP_PDU. These attributes may be a combi- 
nation of universal service attributes and service-specific attributes, and 
in most cases should provide the client with enough information to sub- 
sequently connect to the service. 

The specification defines a third SDP transaction, called the Ser- 
viceSearchAitribute transaction. This transaction consists of a ServiceS- 
earchAttributeRequest SDPJPDU from the client to the server followed by 
a ServiceSearchAUributeResponse SDP_PDU from the server to the client 
It is actually redundant to the first two transactions described above and 
is included for efficiency. What the ServiceSearchAttribute transaction 
allows is the combination of steps 1 and 2. That is, the client can form a 
single request that specifies not only services to search for but also the 
attributes to return for matching services in the server's response. The 
server then responds with handles to matching services as well, as the 
requested attribute values. for those matching services. An implementer 
thus has a choice between the two alternatives for SDP transactions. 10 
More importantly, though, the ServiceSearchAttribute transaction may 
in some cases be more efficient in terms of the number of bytes trans- 
mitted over the air-interface. The consolidated transaction itself 
requires more bytes than the individual transactions but could result in 
fewer total transactions. Especially in cases where many service records 
are being accessed, such as in a service browsing application, the Ser- 
viceSearchAttribute transaction might be more efficient 



10. It should be' noted, however, that different profiles mandate the use of different SDP transac- 
tions, so if a profile is being implemented, the profile will determine which SDP transaction (s) 
need to be used, and the programming effort to support all three transactions should not be 
great. 
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In a nutshell, this is most of what is needed for SDP transactions. 
The specification also includes protocol definitions for special cases, 
including an error response SDP_PDU and a mechanism, called the con- 
tinuation state, for dealing with server responses that cannot fit into a sin- 
gle SDP_PDU. 11 The. syntax of these protocol transactions and the data 
elements that they carry is detailed in the specification and is not repro- 
duced here. A unique feature of the SDP chapter of the specification is 
the inclusion of several detailed protocol examples as an appendix to the 
SDP specification. The members of the service discovery task force of 
the SIG who developed the specification felt that because the actual byte 
streams generated for SDP transactions can be complex (even though 
the transactions themselves are conceptually simple), it would be useful 
to include the examples as a guide for implemented. The complexity is 
introduced mostly when complex data elements (such as DataElementSe- 
quencex, which are lists of data elements and which can be nested) are car- 
ried in the SDP_PDUs. When these complex data types are included in 
SDP_PDUs, or when SDP_PDUs need to be split using the continuation 
state information, the various "count" fields that introduce segments of 
the SDP_PDUs need to accurately reflect the number of bytes that fol- 
low in that segment The examples in the specification serve to clarify 
the correct construction of SDP.PDUs, 12 

Figure 8.4 summarizes the SDP transactions. Shown in the figure 
are representations of the relevant arguments and parameters passed in 
the SDP_PDUs, although these are not complete lists of all arguments 
and parameters; the complete syntax is in the specification: As Figure 
8.3 shows, only services and service attributes that are described by 
UUIDs are searchable. Attributes of a service which are not described 
by UUIDs are not searchable and can be retrieved only after a service 
has been located using a UUID attribute. 



1 1. The client can specify the maximum size for the response to its request SDP_PDU. It is possi- 
ble for the response that is generated by the server to be larger than this maximum size. In this 
case, the server includes some continuation state information at the end of its response, which 
allows the client to initiate another request to obtain the next portion of the response, if desired. 

12. In fact the developers of the specification learned first hand of the need for these examples 
when they constructed them, since there were some errors in the first internal versions of the 
examples. There were even some errors in the examples published in the original version l.OA 
SDP specification, which were subsequently corrected in version 1.0B. 
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Alternalive 1: Individual transactions 
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Figure 8.4 

SDP transaaion summary. 



SDP Usage 

Since SDP was developed primarily for discovering services in Blue- 
tooth environments, the applications most, likely to make use of SDP 
will be those developed specifically to be aware of Bluetooth wireless 
communication (as opposed to legacy applications). One exemplary 
application for SDP usage is what we will call the Bluetooth Piconet 
Minder^ (or BPM application). Such an application is likely to be 
included, in one form or another, in many Bluetooth devices. A BPM 
application as we envision it would present a view of available devices 
and services in proximity (in a piconet) to the user and to other applica- 
tions. This could include a user interface; one might imagine icons or 
other representations of devices and services. Such an application could 



13. This term is used gene neatly here and is not known Co, or intended to, conflict with any actual 
product names. 
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give a user a central point to manage the Bluetooth connections to other 
devices and to select and make use of the services offered by those 
other devices. To support such functions, a BPM application might 
make use of service searching and service browsing and thus initiate 
SDP transactions to populate the service information that is exposed to 
the user and to other applications. 

Certainly other applications designed for use in Bluetooth environ- 
ments might use SDP. Every profile (or at least every "non-generic" 
profile that involves concrete usage scenarios) includes an SDP service 
record to be used when implementing that profile. Applications written 
specifically to exercise the protocol stack will probably need to execute 
SDP transactions to successfully instantiate the profiles. First, such 
applications will need to execute SDP transactions with another device 
to determine if that device offers the desired service, and if so, those 
applications will need to execute additional SDP transactions to obtain 
the information from the service record about how to access that service 
(this can include such information as the required protocol stack and 
associated parameters that the service uses). 

In the case where multiple applications use SDP (perhaps one or 
more profile applications and a BPM application), it may be advanta- 
geous to implement a central SDP client and SDP server that are avail- 
able to all the applications that need them. These SDP "helper 
applications" could be implemented as part of the common services 
layer that was described in Chapter 5. The applications could use the 
platform APIs to access the common SDP services which would gener- 
ate the SDP transactions and pass the retrieved information back to the 
applications. . 

The Service Discovery Application Profile (SDAP) detailed in 
Chapter 12 offers guidance for application interactions with SDP. 
While, as previously noted, the specification does not define APIs, the 
SDAP does define primitive operations that could be mapped to APIs 
and events on many platforms, thus providing a basis for SDP common 
services. 

There may be legacy applications that make use of service discov- 
ery, but such applications probably use some other industry discovery 
protocol (perhaps Jini™, Universal Plug and Play™, Salutation™, Service 
Location Protocol, the IrDA service discovery protocol, or some other 
protocol). Since SDP was developed for Bluetooth applications, legacy 
applications would not be expected to include this protocol without 
modification to the application. Even for these applications, though, 
SDP does offer some accommodation. One of the design points for SDP 
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was to ensure that other popular industry discovery protocols could be 
used in conjunction with it One of the things that can be discovered 
using SDP is that the service supports one or more other discovery pro- 
tocols. Thus SDP might be used in the initial service discovery phase to 
locate the service; further SDP transactions might be used to discover 
that the service supports, say, Salutation; once this has been determined, 
the newly discovered protocol (Salutation in the example) can be used 
for further interaction with the service. SDP specifically supports this 
sort of operation. A SIG white paper [Miller99] describes how Saluta- 
tion can be mapped to SDP. Similar mappings to other technologies 
should be possible, and the SIG is working toward formalizing some of 
these mappings as profiles, as discussed in Chapter 16. 
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procedure follows the guidelines for service discovery found in the 
SDAP, which is presented next 

The Service Discovery Application Profile 

As noted in Chapter 8, service discovery is expected to be a key compo- 
nent of most Bluetooth applications. Nearly all of the profiles include a 
service discovery element Like the GAP, the Service Discovery Appli- 
cation Profile, or SDAP, provides a common and standard method for 
performing service discovery using the Bluetooth protocol stack. 

Unlike most other profiles, the SDAP describes a standard service 
discovery application model and also defines abstractions of service 
primitives that in some respects resemble application programming 
interfaces (APIs). Even though the SDAP deals with the SDP middle- 
ware layer protocol and thus addresses some of the "invisible" opera- 
tions described earlier, it is aimed primarily at application writers. It is 
the only profile with "application" in its title and the only profile to sug- 
gest API-like primitives. As explained in Chapter 8, these primitives 
could be mapped to platform APIs in a straightforward manner. 

SDAP Development 

Both authors have a special interest in the SDAP. Author Bisdikian 
served as editor of the SDAP portion of the specification, conceived the 
original idea for the SDAP and contributed most of its content, and 
author Miller chaired the service discovery task force responsible for 
delivering the SDAP. 

As with the GAP, the need for an SDAP was not originally evi- 
dent, and thus the SDAP was also developed late in the specification 
cycle. Not until January 1999, when most profiles were already under- 
way, was the question raised regarding whether or not a service discov- 
ery profile was needed. By March of that year the idea of an application 
profile for service discovery was accepted and the SDAP development 
proceeded. 

The development of the SDAP is rooted in the fundamental 
assumptions that led to the formation of the SIG itself: the diversity and 
number of devices that would be capable of Bluetooth wireless commu- 
nication and the diversity and number of services available through 
these devices would steadily increase. To keep a semblance of order in 
the expected sea of devices and services available to a user, it was rec- 
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ognized that a standardized procedure should be created that would 
allow the user of a device. to locate and identify services. 

The SDAP does not describe how the service .discovery itself is 
performed; it relies on SDP for this task. Rather, SDAP describes how 
an application that uses SDP should be created and should behave. In 
particular, it defines the functional characteristics of such an application 
through a set of service primitive abstractions, detailed below. Further- 
more, the SDAP defines how other profiles and applications in general 
must use the group of Bluetooth transport protocols to carry 
SDP_PDUs when they need to execute SDP transactions. This latter 
item was an expansion of the SDAP's original scope. All of the "nonge- 
neric" profiles contain an SDP section that provides a list of parameters 
for the protocol stack that leads to the particular application covered by 
the profile. These protocol stack parameters include ones like the 
RFCOMM data link connection identifier (DLCI) needed to reach, say, 
the PPP layer in the LAN access profile. These parameters are carried 
as service attributes within SDP_PDUs. However, these other profiles 
do not specify how the SDP layer could use the group of Bluetooth 
transport protocols to carry these SDP_PDUs. Since the latter process 
should be identical for all profiles, one idea was to include it in a 
generic profile like the GAP. However, the GAP does not focus on the 
transport of data with a source or sink above the L2CAP layer. More- 
over, the SDP specification itself does not contain the dependencies of 
SDP on the group of Bluetooth transport protocols. Even though this 
may seem like an oversight, it was a deliberate choice. The Bluetooth 
service discovery protocol, although tied to systems that utilize Blue- 
tooth wireless communication, is in principle a transport-independent 
protocol. Hence, the SDP specification focuses exclusively on the SDP 
transactions themselves and the various SDPJPDUs that are used, as 
well as the type and form of information that is carried in them. The 
SDP specification does not particularly focus on how these transactions 
are carried over the Bluetooth air-interface. Ultimately, SDAP became 
the only (and natural) point of reference for describing how the SDP 
layers use the group of Bluetooth transport protocols to carry the 
SDPJPDUs to each other. 



m 
m 



SDAP Examined 

The SDAP is unique among the application-oriented profiles, like the 
file transfer profile, the LAN access profile, and. so on. These other pro- 
files describe how the complementary parts of a user-level application 




*tb 2 3 2085 



The Service Discovery Application Profile 2 1 9 



reed that would 

icovery itself is 

describes how 
»uld behave. In 
. an application 
below. Further- 
:ions in general 
>cols to carry 
>ns. This latter 

of the "nonge- 
t of parameters 
ion covered by 

ones like the 
d to reach, say, 
:ers are carried 
: other profiles 
p of Bluetooth 
j latter process 
nclude it in a 
ot focus on the 
P layer. More- 
ependencies of 
en though this 
The Bluetooth 
at utilize Blue- 
rt-independent 
ly on the SDP 
it are used, as 
' in them. The 
se transactions 
SDAP became 

how the SDP 
; to carry the 



ofiles, like the 
lese other pro- 
/el application 



running on two (or more) devices work together to support a particular 
usage scenario. The application in SDAP needs to be present in only 
one device. This application interacts with the SDP layer of the stack in 
the device where it resides to initiate SDP interactions with one or more 
SDP layers in other devices, so as to learn about services in those other 
devices. Upon the arrival of responses from the other devices, the ser- 
vice discovery application can make those results available to the user 
of the device that initiated the transaction(s). 

Often, service discovery in non-Bluetooth environments is per- 
formed by broadcasting inquiries for services or inquiries for locating 
directories of services. In the latter case, when a service directory is 
found, it is then contacted to find out about services that are registered 
there. In a Bluetooth piconet, broadcasts are entirely unidirectional in 
that they are exclusively directed from the master to the slaves of the 
piconet. Furthermore, broadcast transmissions are not recoverable in 
that they cannot be retransmitted following an error in their transmis- 
sion. Thus, service discovery in a Bluetooth piconet does not use a 
broadcast model. Service discovery in Bluetooth piconets is closely 
associated with device discovery. Service discovery is executed only 
between fully identified pairs of devices and only after they have dis- 
covered each other and have created a Bluetooth link (up to and includ- 
ing an L2CAP connection) between them. 

According to the SDAP, devices participating in service discovery 
may have either of the following roles: 

• Local device: This device implements the service discovery appli- 
cation, like the service browsing application referred to in 
Chapter 8. It also implements the client portion of the SDP 
layer. A local device initiates SDP transactions as shown in Fig- 
ure 8.3. 

• Remote device: This device is contacted by a local device to 
inquire about services. A remote device implements the server 
portion of the SDP layer. It responds to SDP transaction 
requests from a local device. To produce its responses, the 
remote, device maintains, explicidy or implicidy, a database 4 
that contains service records for the services available via the 
remote device. 



4. The specification does not define the format of this database, leaving that choice to implement- 
ers. Moreover, this need not be a "database" in the classic sense; it is simply a collection of 
information maintained by the SDP server in a format suitable for the device. 
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Even though some devices may act only as local or as remote 
devices, these device roles are, in general, temporary and meaningful 
only when an SDP transaction between two devices is under way. A 
device can be a local or remote device at different times or even at the 
same time, depending upon when it creates service inquiries or 
responds to. them. The SDAP device roles bear no relation to the base- 
band roles of master and slave, as the latter roles are meaningless above 
the link manager layer. A local device could be either a master or a 
slave in its piconet, as could a remote device. 0 

The SDAP is the only profile that uses the term application in its 
tide. However, the SDAP does not define any particular application. 
Such a definition would be very much platform dependent and possibly 
too restrictive for application developers, neither of which is a desirable 
objective for a specification. However, the SDAP specifies the services 
that a service discovery application should provide to its users to be use- 
ful. These services are summarized in four service primitive abstractions. 
These primitives could be mapped to an appropriate set of APIs based 
upon the underlying software and/or hardware platform in which an 
SDAP application is instantiated. An example mapping of these primi- 
: tives to the Salutation APIs is given in [Miller99], These primitives are: 

• serviceBrowse: This service primitive is utilized when a local 
device wants to perform general service searches, referred to in 
Chapter 8 as service browsing. These searches might take the 
form of queries about what services in general or what services of 
type S are available, if any, via a selected set of remote devices. 
This application-level service primitive results in SDP_PDU 
transactions initiated by any one of the three basic request 
SDP.PDUs presented in Chapter 8: SDP^ServiceSearchRequest, 
SDI^ServiceAttributeRequesty or SDP_ServiceSearchAttributeRequesL 
Optionally, the LMP_name_request PDU could also be sent to 
learn the user-friendly name of the remote device. 

• serviceSearch: This service primitive is utilized when a local 
device wants to perform searches for a specific type of service. 
The search could take the form of queries about what services of 
type S with attributes Al and A2 are available, if any, via a 
selected set of remote devices. Similar to the previous primitive, 



m 



5. ' Often a local device acts as master of a piconet, since typically it would be the device that 
desires to create connections with other devices and search for and use services on them. How- 
ever, this does not mean that a local device must be a master to perform service inquiries. A 
slave device could equally well initiate such inquiries. 




The Service Discovery Application Profile 221 



d or as remote 
and meaningful 
s under way. A 
s or even at the 
ze inquiries or 
ion to the base- 
aningless above 
r a master or a 

pplication in its 
ilar application, 
snt and possibly 
ch is a desirable 
fies the services 
. users to be use- 
ive abstractions. 
;t of APIs based 
ini in which an 
; of these primi- 
primitives are: 

I when a local 
:s, referred to in 
might take the 
what services of 
remote devices. 
; in SDP.PDU 
e basic request 
viceSearchRequest, 
hAttributeRequesL 
also be sent to 
e. 

1 when a local 
type of service, 
what services of 
le, if any, via a 
■vious primitive, 



*e the device that 
rrvices on them. How- 
service inquiries. A 



this application-level service primitive results in SDP_PDU 
transactions initiated by any one of the three basic request 
SDP_PDUs previously mentioned. 
• enumeraURemDev: This service primitive is used when a local 
device wants to search for remote devices in its vicinity. The 
search can be restricted with a class of device (CoD) qualifier to 
search only for devices belonging to the specified class. This 
application-level service primitive results in the local device 
executing inquiries to learn about devices, primarily any new 
devicesi in its vicinity. If, in the future, CoD-specific dedicated 
inquiry access codes (DIACs) are standardized, then the m™™* 
for this primitive could be generated according to these DL\Cs- 
Otherwise, the generic inquiry access code (GIAC) is used and the 
local device needs to filter the received responses according to 
the information included in the CoD field in the FHS BB_PDUs 
received from the responding devices. 
. terminatePrxmitive: This service primitive results in the termina- 
tion of the operations invoked by the previous primitives. 
The first and second primitives above relate directly to transac- 
tions involving SDP_PDUs. The third primitive could be satisfied 
merely by requesting that the device enter the inquiry mode with the 
sole purpose of searching for any other devices in the inquiry scan state 
(as described in the baseband section of Chapter 6). The last primitive 
simply terminates any ongoing actions resulting from the use of any ot 
the other primitives. . 

The SDAP requirements on the Bluetooth stack are straightforward. 
To implement this profile one needs to use nothing beyond the default 
settings for all the protocol layers below the SDP layer. In particular, 
devices that connect for the sole purpose of performing service discovery 
do not need to authenticate each other or encrypt their Bluetooth link. 
The SDP transactions are carried over the ACL baseband link between 
the devices. At the L2CAP layer SDP transactions are earned over con- 
nection-oriented channels configured to carry "best effort" traffic. 

An additional distinction of this profile is that it identifies the con- 
ditions under which L2CAP channels carrying SDP traffic are torn 
down This is so because SDP does not define a session or a transport 



This does not imply that device authentication and/or link encrypuon should not be, per- 
forced. This statement simply implies that the SDAP imposes no ^PTE^t 
exwution. Security i, a. much a usage scenario requirement as a user-level settab le poUcy as 
dossed in the GAP. Security precautions may still be taken for reasons outs.de the scope of 
SDAP. 
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protocol for carrying SDP_PDUs. SDP itself is in essence a connection- .{ 
less protocol. To run the connectionless SDP request/response transac- *, 
tions, the L2CAP layer needs to maintain the U2CAP channel that -\ 
carries the transactions at least for the duration of the transaction. For p. 
efficient use of the transmission resources, the L2CAP channel between I 
an SDP client and an SDP server should be maintained even longer. 
Ultimately, it is the application on behalf of which SDP transactions are I 
executed that should open and maintain, for as long as necessary, the ' 
L2CAP channel for SDP transactions between two devices. 

Summary 

In this chapter we have highlighted the two generic Bluetooth profiles: 
the GAP and the SDAP. The GAP describes the connectivity and secu- % 
rity modes of operation for a device that permits it to discover, be dis- i 
covered by, and create trust bonds and Bluetooth links with other | 
devices. These modes of operation are user- (or application-) settable "1 
device policies that specify how the device should behave relative to i 
other devices with which Bluetooth communication might ensue.. 

The SDAP describes the functional characteristics of a service dis- 
covery application. Furthermore, and equally importandy, the SDAP 
describes the way that the SDP layer must use the group of Bluetooth 
transport protocols to carry SDP transactions. This aspect of the SDAP 
also forms the basis for executing service discovery within the other 
profiles. 
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